How does the queueing thing works in GW? - Guild Wars Forums

pumpkin pie · Jul 13, 2008, 07:48 AM // 07:48

I am wandering, cos of the double arena weekend as to how the queueing works.

once a player click the join/enter battle button, does your nick name goes into a queue, and game will assign 4 players every battle each side according to the time you click enter battle. i think thats logically it, right??

So I was thinking, what if, how about, Arena net change the queueing system to a click-pool-queue system? (i came up with that name :P) when all the players who click enter battle/join, these players will be chuck into a pool and the game system will jumble them, it then make random selection of 4 players to a team and put them into another waiting room, click-jumble-queue, hence lowering the possibility of a successful sync.

You think that could work? Do you have a good solution?

Rampager · Jul 13, 2008, 07:53 AM // 07:53

sounds like more lag im alright thanks

Pleikki · Jul 13, 2008, 08:21 AM // 08:21

I agree that text above, sound more laggy

pumpkin pie · Jul 13, 2008, 08:25 AM // 08:25

you mean lag as in the battle or waiting?

okay, for below answers, thanks , i guess you mean the waiting part then.

Rampager · Jul 13, 2008, 08:48 AM // 08:48

Quote:

Originally Posted by pumpkin pie

these players will be chuck into a pool and the game system will jumble them, it then make random selection of 4 players to a team and put them into another waiting room,

12 characters and stuff

Fril Estelin · Jul 13, 2008, 09:42 AM // 09:42

Quote:

Originally Posted by pumpkin pie

You think that could work? Do you have a good solution?

I don't know the GW's server specifics, but I feel that (despite this being an excellent idea) it would add just a little bit more load to the server. Linked lists (which may implement queues effciciently) are used because it's easy to manage, thus fast. Your idea would require a "set" data structure, where you can basically pick elements in a non-sequential manner. Tables can implement that well, but then you have to keep track of empty slots, which adds to the management.

Good idea, that was already suggested IIRC, worth the investigation effort by the GW1 programmer that is left (if it wasn't done already...).

Edit: regarding waiting times, you can easily disable this system when there aren't enough players (a situation where sync would happen anyway).

crazybanshee · Jul 13, 2008, 01:48 PM // 13:48

I like that you're trying to come up with a solution for syncing players (who I like to call 'cheaters') You see them in every 'random' pvp arena (snowball, dragon arena, costume brawl as well as ra) Not exactly a perfect idea but it doesn't matter anyway since anet will not do that kind of overhaul at this point.

lord of all tyria · Jul 13, 2008, 02:02 PM // 14:02

Syncing is fun when I'm bored. Because more often that not we end up on opposing teams.

thedarkmarine · Jul 13, 2008, 02:24 PM // 14:24

Longer waits would not be a problem; for everyone person that is waiting longer, someone just got in faster. Thus, the wait on average should be about the same. The only problem is the people who might get really unlucky that wait a really really long time.

This is the type of problem people encounter when programming an operating system. If I'm not mistaken, multi-threading is the issue: which thread should be the next to get a processor time? Using a queue or randomly picking one are both fine.

Antheus · Jul 13, 2008, 02:26 PM // 14:26

Quote:

Originally Posted by Fril Estelin

I don't know the GW's server specifics, but I feel that (despite this being an excellent idea) it would add just a little bit more load to the server. Linked lists (which may implement queues effciciently) are used because it's easy to manage, thus fast. Your idea would require a "set" data structure, where you can basically pick elements in a non-sequential manner. Tables can implement that well, but then you have to keep track of empty slots, which adds to the management.

Neither of these add to lag. From code perspective, both are trivial, and neither require linked list or set. Data structure overkill. We're literally talking nanoseconds to perform either selection.

Players want to join ASAP. As such, they are given a window of 30 seconds, after which they are picked. Nobody knows how many players join in that time. But if this number is low, 4-12, then jumbling will not change much, since probability of syncers being selected isn't decreased much.

zwei2stein · Jul 13, 2008, 02:56 PM // 14:56

Quote:

Originally Posted by Antheus

Neither of these add to lag. From code perspective, both are trivial, and neither require linked list or set. Data structure overkill. We're literally talking nanoseconds to perform either selection.

This is kind of reasoning which explains why we nowadays need quad core computers for simple word procesors.

Fril Estelin · Jul 13, 2008, 08:09 PM // 20:09

Quote:

Originally Posted by zwei2stein

This is kind of reasoning which explains why we nowadays need quad core computers for simple word procesors.

I was going to reply, but fortunately I saw your answer (actually it's all about the server business, but the point is exactly the same). It disappoints me that there's a science for computers and yet no one can make a difference today in general computing public (aka geeks) between a linked list and a table. Efficient and top-notch implementation is the reason why GW is f2p (I read Jeff Strain saying that about GW1 several times and he said it again in the latest GW2 article in German).

Well let's hope that an Anet dev will read this thread and think "it's time we move from DoubleLinkedList objects to ComplexQueues"!

buckscrib · Jul 14, 2008, 02:42 AM // 02:42

We already wait long enough. This would increase it.

Jul 13, 2008, 07:48 AM // 07:48	#1
pumpkin pie Furnace Stoker Join Date: Jul 2006 Location: behind you Guild: bumble bee Profession: E/	How does the queueing thing works in GW? I am wandering, cos of the double arena weekend as to how the queueing works. once a player click the join/enter battle button, does your nick name goes into a queue, and game will assign 4 players every battle each side according to the time you click enter battle. i think thats logically it, right?? So I was thinking, what if, how about, Arena net change the queueing system to a click-pool-queue system? (i came up with that name :P) when all the players who click enter battle/join, these players will be chuck into a pool and the game system will jumble them, it then make random selection of 4 players to a team and put them into another waiting room, click-jumble-queue, hence lowering the possibility of a successful sync. You think that could work? Do you have a good solution?

Jul 13, 2008, 08:25 AM // 08:25	#4
pumpkin pie Furnace Stoker Join Date: Jul 2006 Location: behind you Guild: bumble bee Profession: E/	you mean lag as in the battle or waiting? okay, for below answers, thanks , i guess you mean the waiting part then. Last edited by pumpkin pie; Jul 13, 2008 at 09:05 AM // 09:05..

Jul 13, 2008, 07:53 AM // 07:53	#2
Rampager Krytan Explorer Join Date: May 2006 Location: Australia Profession: Mo/	sounds like more lag im alright thanks

Jul 13, 2008, 08:21 AM // 08:21	#3
Pleikki WTB q8 15^50 Weapons! Join Date: Nov 2006 Guild: ???oo ???ugs ???lan [?????????]	I agree that text above, sound more laggy

Jul 13, 2008, 01:48 PM // 13:48	#7
crazybanshee Desert Nomad Join Date: Jun 2006 Location: Look out! Profession: E/	I like that you're trying to come up with a solution for syncing players (who I like to call 'cheaters') You see them in every 'random' pvp arena (snowball, dragon arena, costume brawl as well as ra) Not exactly a perfect idea but it doesn't matter anyway since anet will not do that kind of overhaul at this point.

Jul 13, 2008, 02:02 PM // 14:02	#8
lord of all tyria Lion's Arch Merchant Join Date: Mar 2007	Syncing is fun when I'm bored. Because more often that not we end up on opposing teams.

Jul 13, 2008, 02:24 PM // 14:24	#9
thedarkmarine Lion's Arch Merchant Join Date: Mar 2006	Longer waits would not be a problem; for everyone person that is waiting longer, someone just got in faster. Thus, the wait on average should be about the same. The only problem is the people who might get really unlucky that wait a really really long time. This is the type of problem people encounter when programming an operating system. If I'm not mistaken, multi-threading is the issue: which thread should be the next to get a processor time? Using a queue or randomly picking one are both fine.

Jul 14, 2008, 02:42 AM // 02:42	#13
buckscrib Frost Gate Guardian Join Date: Jan 2006 Guild: COL	We already wait long enough. This would increase it.